Conversation
|
|
I'm a little intrigued - can you say more about the specific layer configuration that was unpickleable? Feel free to message me if that involves too many customer specifics to post here |
| assert status == HTTPStatus.OK | ||
|
|
||
| assert content["domain"]["ranges"][parameter_name]["axisNames"] == list(layers[0].node.find_coordinates()[0].dims) | ||
| assert set(content["domain"]["ranges"][parameter_name]["axisNames"]) == {"lat", "lon", "time"} |
| "start": x_arr[0] if len(x_arr) > 0 else None, | ||
| "stop": x_arr[-1] if len(x_arr) > 0 else None, |
There was a problem hiding this comment.
good additional case handling!
|
|
||
| if crs.lower() not in [key.lower() for key in settings.EDR_CRS.keys()]: | ||
| raise ProviderInvalidQueryError("Invalid CRS provided.") | ||
| msg = f"Invalid CRS provided, expected one of {', '.join(settings.EDR_CRS.keys())}" |
There was a problem hiding this comment.
I like all these more-informative error messages!
It's always worth thinking about, from a security persepective, whether providing additional information with an error message will reveal anything that would aid an attacker. The list of supported CRS's is not a private piece of information, and all the other messages also look good to me, I just figured I'd mention it.
jdw-creare
left a comment
jdw-creare
left a comment
There was a problem hiding this comment.
This all looks good to me! I have no changes to recommend so I'll merge it!
For posterity: Sam answered this question in a private message |
2 participants
Additional fixes for the EDR endpoints: